Drop redundant GuardAnchors type alias in file_edit_insert

In src/node/services/tools/file_edit_insert.ts, GuardAnchors was defined as Pick<InsertContentOptions, "insert_before" | "insert_after">, but InsertContentOptions itself is already Pick<FileEditInsertToolArgs, "insert_before" | "insert_after"> after the .nullish() strict-mode refactor in #2250 stripped the InsertContentOptions interface down to those same two fields. The two aliases became structurally identical, so GuardAnchors is dead.

Drop the alias and use InsertContentOptions for the two callers (insertWithGuards, resolveGuardAnchor). Both names were file-local; no exports change. The function names already convey "guard" context, so the parameter type doesn't need to repeat it. This noise was especially visible to the new guardless-empty-file path added in #3220 since it sits next to insertContent which uses InsertContentOptions.

Pure type-level cleanup — emitted JS, runtime behavior, and the public tool surface are all unchanged.

Extract ResolvedWorkspaceAiSettings type alias in taskService

The shape { model: string; thinkingLevel?: ThinkingLevel } (used internally to read per-agent AI settings off partial workspace metadata) was duplicated 7 times across the parameter and return types of resolveWorkspaceAISettings, resolveTaskAISettings, and resolveParentAutoResumeOptions in src/node/services/taskService.ts. The new sub-agent defaults split (#3215) made this duplication especially visible because it added a third method copying the same inline shape.

A private ResolvedWorkspaceAiSettings interface at module scope replaces all 7 inline occurrences. Pure type-level cleanup — emitted JS, runtime behavior, and the schema-derived WorkspaceAISettings type (where thinkingLevel is required) are all unchanged. The new interface is intentionally local to this file (not exported) since it captures the looser internal-reader shape, distinct from the canonical schema-derived type.

Extract shared ServiceTier type from ServiceTierSchema

The OpenAI service-tier literal union ("auto" | "default" | "flex" | "priority") was duplicated in three places: the CLI options interface (src/cli/run.ts), the providerModelFactory cast at the providers.jsonc boundary (src/node/services/providerModelFactory.ts), and a local OpenAIServiceTier alias in ProvidersSection.tsx. ServiceTierSchema (src/common/config/schemas/providersConfig.ts) already defines the same enum as the runtime source of truth, so this change derives a TypeScript ServiceTier alias via z.infer once and imports it at each site.

The Settings UI keeps its OpenAIServiceTier local alias (used by OpenAIServiceTierSelectValue and the isOpenAIServiceTier type guard) but it is now type OpenAIServiceTier = ServiceTier, so the disambiguating name and call sites stay intact.

Drop unused appendSpace literals on skill/model alias suggestions

In src/browser/utils/slashCommands/suggestions.ts, the SuggestionDefinition literals built for agent skills and model alias one-shots set appendSpace: true, but the build callbacks for those two paths hardcode the trailing space and never read definition.appendSpace. Only the top-level command and subcommand build callbacks consult the field. Remove the no-op appendSpace: true from the skill and model alias mappings and leave a short comment near each so a future reader doesn't assume the field is consulted on these paths.

Behavior is preserved — the field is unread on these paths, and the existing suggestions.test.ts / inlineSkillSuggestions.test.ts / suggestionMatching.test.ts suites all still pass.

Route ThemeContext color-scheme through isLightThemeMode

Replace the inline theme === "light" || theme === "flexoki-light" check in getColorScheme (in src/browser/contexts/ThemeContext.tsx) with the shared isLightThemeMode helper from src/browser/utils/highlighting/shiki-shared.ts.

The helper was just introduced as the single source of truth for the -light suffix → light-theme mapping, and the highlighting call sites (MarkdownComponents, HighlightedCode, highlightDiffChunk) already use it. This change extends that convention to ThemeContext so a future palette like solarized-light would automatically map to colorScheme: "light" without revisiting this site.

Behavior is preserved: for the four valid ThemeMode values ("light", "dark", "flexoki-light", "flexoki-dark"), isLightThemeMode returns the same result as the previous explicit comparison.